Moi — C'était sympa hier de faire un gemba chez nous hier.

X — Oh tu sais, je n'ai pas fait grand chose : juste pointer là où je comprenais des trucs et là où je ne captais pas grand chose.

Moi — N'empêche que tu as appuyé là où ça faisait mal. La fin de l'année est un des moments où je me pose des tas de questions pour ré-orienter les équipes. J'avais commencé par supprimer un certain nombre de zones au coeur de notre obeya, sans pour autant les remplacer : je m'en suis mordu les doigts en imaginant mes propres équipes attendre la suite, un peu perplexe de ce vide.

X — J'ai quand même eu l'impression de faire du "rubber duck gemba walk", comme on ferait du "rubber duck debugging" sur du code bien poilu. En te voyant articuler tes problématiques à l'oral - et presque au pied levé - je voyais bien que ça cogitait là-dessous. Et c'est tout l'attrait de ces gemba walks improvisés quand la confiance est pré-existante : même quand je découvre un environnement entièrement nouveau, les lunettes Lean révèlent des trucs intéressants, quand bien même ils m'échappent ! C'est puissant et troublant à la fois.

Moi — Tu ne penses pas si bien dire : ça m'a juste botté les fesses. Je tournais autour du pot depuis de trop longues semaines.

X — Alors ça donne quoi ?

Moi — Remettre des étoiles du nord en haut de nos murs : "50 clients en plus" d'une part et "10 clients qui nous adorent" d'autre part.

X — Je distingue déjà des efforts qui doivent guider tes équipes sur du Just-in-Time pour la première et du Jidoka pour la seconde. Je me trompe ?

Moi — Même pas ! On revient toujours au basique... C'est d'ailleurs ce que je retiens de ton passage d'hier : il y a tellement de techniques dans le Lean qu'il est très facile de se fourvoyer dans les outils. Alors même que la stratégie peut être très simple : il suffit souvent de commencer par aller chercher les problèmes des clients. Puis d'y faire face !

X — Est-ce qu'on pourrait se faire une petite réunion bientôt ?

Moi — Non.

X, déstabilisée — Mais j'ai quand même besoin de te voir avec la développeuse : le client trouve qu'il y a trop de boutons sur un formulaire et voudrait qu'on ajoute des couleurs pour mieux les différencier.

Moi — Et est-ce que tu es d'accord avec ça ?

X — Pas vraiment. La charte de l'application n'indique que deux couleurs (vert = OK, rouge = KO) et on a déjà été contraint de valider une couleur verte en plus, plus foncée. Je me vois mal en ajouter encore une en plus, alors en ajouter deux !

Moi — Et qu'est-ce qu'en dit la développeuse ?

X — Qu'elle n'est pas chaud non plus.

Moi — Alors qu'est-ce qu'elle propose ?

X — Elle dit que c'est à moi — la designeuse — de trouver quelque chose de mieux. Et c'est pour cela que je voudrais faire cette réunion : j'en ai besoin pour avancer.

Moi — Je crois que tu veux simplement éviter de réfléchir.

X — Au contraire, je pense qu'on réfléchit mieux à plusieurs.

Moi — Et tu penses vraiment qu'attendre quelques jours pour trouver une date à trois, puis s'enfermer dans une petite salle et espérer que la bonne idée tombe du ciel soit le meilleur plan ?

X — Dis comme ça...

Moi — On a sur les mains un cadeau : un bon problème. Et toi comme moi, on sent bien que la proposition du client nous emmène doucement dans les marécages gluants de la pensée feignante.

X — Alors qu'est-ce que tu proposes ?

Moi — Je t'invite à réfléchir, à creuser le problème, à entrouvrir des contre-mesures... Et je te propose même un chemin : poser des questions aux uns et aux autres.

X — Quelle différence avec une réunion ?

Moi — Rien à voir, je te demande de prendre ce problème à bras le corps. C'est le côté stimulant d'un problème : accepter de s'y confronter et s'en servir pour s'améliorer. Le "teamwork" du Lean, ce n'est pas de refiler la patate chaude à quelqu'un d'autre ou de la diluer dans un groupe. C'est plutôt de demander à un développeur si ta dernière idée est faisable techniquement, d'apprendre le pourquoi et de découvrir les bornes du domaine des solutions. Et au passage de créer un tissu de confiance : on ne fait équipe qu'à partir du moment où chacun est à l'aise pour parler avec tous les autres, individuellement.

X — Justement je me demandais pourquoi il y a avait 4 boutons sur cette page. Est-ce que tu penses qu'on pourrait en supprimer un ou deux ? Cela pourrait aussi résoudre le problème.

Moi — Est-ce que tu crois que j'ai la réponse ?

X — J'imagine qu'il faudrait plutôt poser la question au responsable de ce client en particulier, ou même au client directement.

Moi, malicieux — Est-ce que l'un ou l'autre était prévu dans ta réunion initiale ?

X — Bien sûr que non, pour moi, c'était un problème technique...

Moi — On arrive donc au coeur du sujet : en faisant une réunion, on serait passé à côté d'une si belle occasion de casser du silo.

X — Intéressant d'avoir utilisé la mise sous enveloppes de notre première campagne de communication papier pour faire un pseudo-atelier cocottes. J'ai l'impression d'avoir mieux compris des trucs du Lean.

Moi — Alors qu'est-ce que tu en as retenu, à chaud ?

X — Le truc qui fait le plus mal, c'est d'avoir perdu un tour bêtement. On s'est tout de suite tellement focalisé sur le flux - aller le plus vite possible - qu'on ne s'est même pas rendu compte des défauts sur les enveloppes. Pas une de correct, elles étaient toutes gondolées ou mal collées.

Moi — Alors que tout le monde sait évidemment mettre deux feuilles dans une enveloppe avant de la fermer !

X — Heureusement qu'on a creusé cet aspect qualité d'ailleurs : on aurait pû vite rester bloqué sur le poste qui n'arrivait pas à mettre les feuilles dans l'enveloppe alors que le problème était deux postes en amont sur le pliage des feuilles. Si les plis ne sont pas exactement à un tiers de la feuille, elle devient presque impossible à glisser dans l'enveloppe au bon tempo : il y a toujours un coin à forcer ou à repositionner.

Moi — Un bel exemple de jidoka.

X — Carrément : vu qu'on s'est arrêté pendant le tour, on a réussi à remonter facilement jusqu'au poste qui produisait de la non-qualité pour l'aval. Alors même qu'il ne s'en rendait pas compte du tout.

Moi — D'autres trucs que tu as sentis ?

X — L'état de fluidité à la fin : on avait l'impression que tout coulait. Une belle horlogerie ! Quand tu déposes la feuille pliée alors que la précédente vient d'être prélevée par le poste suivant, quelle sensation étrange : c'est très satisfaisant. Comme si tout roulait sans entrave.

Moi — On parle parfois du flow pour toucher du doigt ce sentiment. Mihaly Csikszentmihalyi en a fait un livre très intéressant (et une vidéo TED pour les pressés). Il y montre en particulier que même un opérateur sur une chaîne industrielle peut vivre cette expérience.

X — J'imagine que toute la difficulté tient à maintenir cet état.

Moi — Précisement, c'est pourquoi on insiste tellement sur la maintenance dans le Lean : devoir s'arrêter parce que la machine ne fonctionne pas bien est un manque de respect auprès des opérateurs. Eux aussi ont droit de travailler dans de bonnes conditions.

X — Faut dire quand même que nous avons fait des tours assez courts : quelques minutes de production, avant d'explorer comment améliorer le process.

Moi — Je n'ai jamais dit que la maintenance était la panacée : avoir du temps pour se faciliter la vie au travail est aussi primordial, surtout quand on le couple avec le droit d'arrêter la chaîne.

X — Encore un truc que je dois apprendre : jamais je n'aurais eu l'idée de refuser de travailler alors même que je sentais bien que mes enveloppes n'étaient pas top quand je les terminais lors du premier tour.

Moi — Et surtout un truc que je ne transmets pas assez.

X – Ça fait maintenant un ou deux ans que je lis régulièrement tes billets sur le Lean. J'ai l'impression que ça pourrait répondre à des questions que je me pose...

Moi – Je suis touché : ce n'est pas si souvent que j'ai un retour sur ces billets de blog plus ou moins réguliers.

X – Je me pose donc la question de m'y mettre. Comment faire ? Est-ce que tu aurais un tuyau ?

Moi – Si tu m'avais posé la question il y a quinze jours, je t'aurais répondu Le Goldmine : l'histoire romancée d'une transformation Lean dans une usine. Mais depuis la publication de Réussir ses décisions stratégiques, j'ai le sentiment que ce petit opus de Michael Ballé, Godefroy Beauvallet et Sandrine Olivencia serait une porte d'entrée plus adaptée.

X – C'est justement celui que j'ai lu sur ma kindle après avoir vu passer un billet sur ton blog.

Moi – Alors c'est génial, tu as déjà commencé. Maintenant il faut simplement avancer et tenir bon... Le sérieux et la ténacité sont des vertus cardinales quand on se lance dans le Lean.

X – Bien sûr je comprends tout ça, je me familiarise d'ailleurs tout doucement avec les concepts mais j'aurais besoin d'un truc plus terre à terre.

Moi – S'il te faut plus de terrain, je peux te suggérer de faire un peu de genchi genbutsu avec tes équipe. Le Gemba code en est une des formes possibles : on part d'un bug - chez nous une notice ou un warning détecté par les serveurs de production - et on explore en binôme les causes, puis on fait la correction qui s'impose avant de noter sur un A4 ce qu'on a appris au passage. Cela me prend une heure par semaine, à tour de rôle avec chaque développeur.

X – Et tu arrives à maintenir le rythme ?

Moi – Pas toujours, il y a effectivement des congés ou des déplacements qui contraignent mon agenda. Mais si je ne peux pas tenir la cadence alors je m'assure qu'un autre développeur prendra la relève. Sur les 25 dernières semaines, le Gemba code a eu lieu 24 fois. C'est Noël qui a fait déraillé cette routine la dernière fois...

X – Sauf que moi, je ne suis pas développeur : comment voudrais-tu que je comprenne ce que mes équipes font derrière leur écran ? Surtout qu'on s'appuie sur une brique externe, une véritable boîte noire sur laquelle nous n'avons pas la main. Bref on a un contexte technique moins évident que celui dont vous bénéficiez avec Opentime.

Moi – Et tu as essayé de contacter directement des senseïs ? Nous avons de la chance d'en avoir sur la région... Même plus besoin d'aller en chercher à Paris !

X – J'ai bien peur que ça fasse un sacré budget quand même. On n'est pas encore un grand groupe avec ses armées de consultants.

Moi – Mais au fait, vous êtes combien désormais ? La dernière fois qu'on avait papoté ensemble, vous veniez de passer pour la première fois la barre des 10 salariés.

X – C'est vrai qu'on a fait un bout de chemin depuis cette époque. On est désormais une vingtaine, c'est quand même une belle croissance.

Moi – Ah je comprends mieux : tu n'as pas encore besoin du Lean. C'est une piste que tu peux garder au chaud dans un coin de ta tête. Pour l'instant tu peux juste attendre d'avoir des vrais problèmes. Et si tu as envie de t'en sortir à ce moment-là, on pourra en reparler.

X – C'est bon j'ai fini ma tâche, est-ce qu'on peut la regarder ensemble pour la valider ?

Moi – Bien sûr...

Moi, confiant après 5 minutes à relire le code – C'est tout bon, on peut l'ajouter dans le dépôt source.

X – Je fais un merge avec la branche principale et après je pousse tout sur le serveur central. C'est bien ça ?

Moi – Exact, il suffit de bien suivre la petite procédure interne (checkout, rebase, merge, dcommit, push) qui t'explique chaque étape dans le wiki interne.

X – Je me souviens bien de ces procédures, je les ai d'ailleurs suivi pour installer le code source sur mon ordinateur au départ.

X, contrarié – Par contre là, ça ne marche pas : je n'ai rien fait de particulier et pourtant Git me dit que j'ai des commits d'avance ! Ce n'est quand même pas de ma faute si ça ne marche pas du premier coup...

Moi, sarcastique – As-tu vérifié s'il n'y avait pas un petit lutin ou pire un farfadet sous ton clavier ? Peut-être qu'ils ont laissé des traces de leur passage ? Des miettes de pain peut-être ou des gouttes de lait ?

X – Ce n'est pas ce que je voulais dire...

Moi – Alors qu'est-ce que tu voulais dire ?

X, vexé – Que je ne sais pas ce que j'ai fait et que je comprends encore moins pourquoi ça ne marche pas... Mais que le code est bon.

Moi – Sauf qu'en l'état le code ne sert à rien : impossible de le fusionner dans le dépôt central.

X – Mais qu'est-ce que je peux faire alors ?

Moi – La première étape, c'est peut-être d'assumer que tu as fait une erreur et que tu es en train d'apprendre. Tu débutes chez nous, c'est normal. J'irai même jusqu'à dire que savoir trouver de l'aide fait parti de l'apprentissage.

X – Tu veux dire que je dois lire toute la documentation de Git pour comprendre comment résoudre ce problème ?

Moi – C'est une piste. Tu peux aussi repartir d'une installation complètement vierge. Tu peux également demander à un développeur senior de te montrer comment il s'en dépatouillerait. Tout dépend de ce que tu veux apprendre et à quelle vitesse surtout.

X – Mais qu'est-ce que je dois faire alors ?

Moi – Gagner en humilité et en expérience ! Et pour ça, ces trois chemins sont valables. Probablement même qu'il y en a d'autres...

X, impatient – Tu ne me diras donc pas lequel il faut que je prenne.

Moi – Je ne peux pas le faire pour toi : les adultes apprennent moins bien quand on leur montre trop précisément chaque étape. Ils ont déjà un tas de modèles mentaux à leur disposition, des modèles qui les ont aider devenir ce qu'ils sont, des modèles qui ont déjà fait preuve de leur efficacité. Si tu ne sais pas quel chemin prendre, l'expérience douloureuse d'un choix sera bien meilleure conseillère à terme : c'est peut-être le plus facile.

X – Parce que tu penses que ça peut être plus rude ?

Moi – Si tu feins de ne pas le savoir - peut-être qu'un de tes réflexes te suggère d'ailleurs très légitimement de "retourner la question pour ne pas être pris en défaut" -, alors il te faudra d'abord casser, affiner ou ajouter un modèle mental. C'est loin d'être si évident. Et là encore, personne ne peut le faire à ta place.